An IC card comprises at least a memory unit that stores one or more applications, such as an application to interface a payment system or an application for a verification or identification system, for example. With reference to FIG. 1, an IC card 1 comprising a memory unit for storing an application 2 is schematically represented.
The current manufacturing process provides for a procedure wherein an IC card manufacturer 9 is in charge of a pre-personalization phase of the IC card 1. For example, the IC manufacturer is asked to define the IC card file structure and/or a data structure for managing file and data storage, as well as storing secure keys and one or more applications 2 inside the memory unit.
More particularly, the applications 2 are stored by the IC card manufacturer 9 in a basic version and are personalized only after the pre-personalization phase. The IC card manufacturer 9 then releases the IC card 1 to an issuer entity 4, generally providing a how to do method for helping the issuer entity 4 for managing the personalization of the IC card 1.
The application 2 comprises a plurality of application data 3 that needs to be initialized by the issuer entity 4 before the final releasing of the IC card 1 to a cardholder 5. The issuer entity 4 uses a personalization device 8 for sending a plurality of personalization commands 6 to the IC card 1. The personalization command 6 initializes the application data 3 to corresponding values. More particularly, the issuer entity 4 prepares a set of personalization data 7 to be entered to the personalization device 8, wherefrom corresponding personalization commands 6 are generated and sent to the IC card 1.
A format of such personalization data 7 depends on the application 2, and also the internal file and data structure of the IC card 1 that hosts such an application. In fact, a same application 2 stored on two different IC cards 1, respectively provided by two different IC card manufacturers 9, could require different personalization data to be initialized.
So the issuer entity 4 should write personalization data 7 according to the file and/or data structure of the IC card 1, as well as other internal specifics of the IC card 1. For example, the secure keys may be pre-stored, the basic version of the applications 2 may be pre-stored in the memory unit, and so on.
According to the upgrading of an application 2, the issuer entity 4 needs to provide a new set of personalization data 7 intended to personalize such an upgraded application 2. In the same way the issuer entity 4 should act when the file and/or data structure definition of the IC card 1 is changed, for example due to an upgrading of a microchip hosted inside it. The new personalization data 7 is to comply to the new release of the application 2, or to the new IC card microchip.
For this reason, the preparation of personalization data 7 is particularly expensive and time consuming for an issuer entity 4, especially considering the increasing number of applications 2 hosted in an IC card 1. To address this problem some well known credit card payment systems, for example Europay, Master Card International and Visa International Service have adopted a common method to personalize the application 2. This is done with the objective of reducing the cost of personalization, and facilitating the migration to new microchip and/or applications 2.
This common method, actually known as EMV CPS (Europay Master Card International and Visa International Service Card Personalization Specification), is referred by designers of applications 2, designers of personalization device 8 and designers of personalization data 7 to simplify the personalization of IC card applications 2. More particularly, not only CPS (Card Personalization Specification) but a general method to personalize applications could be implemented and could provide the same benefit provided by CPS if it were adopted as a standard for personalization.
As CPS has been promoted on a wide scale, it has become a recognized standard by payment systems. CPS offers benefits which include lower set up costs, a faster time to market, greater choice of suppliers (manufacturer and personalization bureau) and an enhanced ability to switch suppliers.
According to CPS, the personalization data 7 are organized into data groupings, as schematically shown in FIG. 2. Each data group is identified by a data grouping identifier DGI, followed by the length of the data group and its value. During the personalization of the IC card 1, the personalization device 8 parses a list of data groups and sends it to the IC card 1. On receipt, the IC card application 2 uses the data grouping identifier DGI to determine how the data grouping received from the personalization device 8 is to be processed.
CPS may be used also to create a file system for the IC card. More particularly, a file system created with CPS comprises a plurality of elementary files EFs with a linear structure and records of variable sizes. Each elementary file EF is referenced through a short file identifier SFI, as schematically shown in FIG. 3A.
Unfortunately, in a file system created through CPS, the standard ISO security attributes are not provided. These attributes are generally used for defining an access level to elementary files EFs. In a file system created with CPS, a terminal connected to the IC card may only read records of elementary files EFs through specific commands, such as through a READ RECORD command, for example.
A list AFL identifies the files and records to be used in processing of a transaction, and defines the records that may be acceded. In other words, there is a possibility of not defining the access level on the elementary record. This is a record accessibility predefined and not changeable during personalization. To create the file system of an application 2 through the CPS common method, only the record values need to be personalized.
With reference to FIG. 3A, the first byte of the data grouping identifier DGI indicates the SFI of the elementary file EF containing the record. The second byte indicates the record number, and the data grouping is the record for the application. Even if a file system created with CPS is particularly indicated to guarantee security of a payment system, it is not indicated for applications 2 requiring the definition of an access level on elementary files.
Some applications 2 in fact, generally not directed to banking systems, need to define an access level to the application data, and consequently they are not created through the CPS common method. Such applications 2 need a file system supporting the definition of access level in single elementary files. Access conditions to application data 3 of the IC card application 2 are defined by personalization data 7.
With more specific reference to FIG. 3b, schematically represented is a first plurality of files respectively indicated with file identifiers fidA, fidB, fidC, fidD, and fidE. The files represent an application 2 in a first file format for an IC card 1.
Each single file fidA, fidB, fidC, fidD, and fidE comprises a plurality of data associated to a corresponding offset into a file body. For example, the file identified by file identifier fidA comprises three data, respectively indicated with dataA1, dataA2, and dataA3.
The first format representing the application 2 allows definition of an access level for each file fidA, fidB, fidC, fidD, fidE of the application 2. More particularly, different data dataA1, dataA2, dataA3 inside a same fidA cannot be associated to different access levels. In other words, a grouping of information inside the application 2 is based on access level, and information cannot be grouped by logical content. This is because an access level is related to a file fidA, fidB, fidC, fidD, fidE and not to a single data, dataA1, dataA2, dataA3.
Actually, it is not known how to create a file system for an application 2 through a common method, as CPS, and keeping at the same time the possibility to define the access level on its elementary files. Nor is there a known method to create personalization data 7 for an application 2 based on a file system that supports definition of the access level.
The current common practice is to provide different IC card manufacturers 9 designs of their own file system, and their own application. This leaves to the issuer entity 4 the burden to personalize the applications 2 with personalization data 7. This personalization data 7 is difficult to prepare, time consuming and subject to modification due to the changing or updating of applications, as well as to the changing of the manufacturer 9 supplying such an IC card 2.